-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(world): encapsulate functionality [N-01] #2157
Conversation
|
7090e77
to
15d6026
Compare
5881958
to
06f2ca2
Compare
packages/world/src/modules/core/implementations/AccessManagementSystem.sol
Outdated
Show resolved
Hide resolved
* @dev Unregisters the system at the given ID | ||
* @param systemId The unique identifier for the system | ||
*/ | ||
function unregisterSystem(ResourceId systemId) public virtual { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we intentionally don't allow for unregistering systems? cc @alvrs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from @alvrs via discord
yeah it's this weird situation where other contracts that interact with yours might break if you unregister function selectors or unregister systems, so I think we should only encourage upgrading systems in a non-breaking way
if someone really wants to remove a system or function selector they can do it by editing the tables, but i don't think it should be something we encourage
683cdb3
to
eaea087
Compare
@@ -250,7 +251,9 @@ contract WorldTest is Test, GasReporter { | |||
coreRegistrationSystem.registerFunctionSelector.selector, | |||
coreRegistrationSystem.registerRootFunctionSelector.selector, | |||
coreRegistrationSystem.registerDelegation.selector, | |||
coreRegistrationSystem.registerNamespaceDelegation.selector | |||
coreRegistrationSystem.unregisterDelegation.selector, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oof, we didn't have this before, eh?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another reason for #2155
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, this was forgotten. Although this is a test file so whatever automation we add needs to apply here too.
function renounceOwnership(ResourceId namespaceId) public virtual onlyDelegatecall { | ||
// Require the namespace ID to be a valid namespace | ||
requireNamespace(namespaceId); | ||
|
||
// Require the caller to own the namespace | ||
AccessControl.requireOwner(namespaceId, _msgSender()); | ||
|
||
// Delete namespace owner | ||
NamespaceOwner._deleteRecord(namespaceId); | ||
|
||
// Revoke access from old owner | ||
ResourceAccess._deleteRecord(namespaceId, _msgSender()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we just call transferOwnership
with address(0)
here? Similar to the Ownable lib: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/e5c63635e3508a8d9d0afed091578cc4bb59a9c7/contracts/access/Ownable.sol#L77
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could transfer to address 0 and then delete the resource access record. No strong opinion though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that would basically be the same logic but a few extra writes, wouldn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting pattern, but it ~doubles the gas from 35488 to 74700. Plus, setting then deleting the ResourceAccess
record seems potentially more confusing then not? Unless folks feel strongly i think the inlined code is fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine how it is, but I did make a code suggestion below for completeness with other audit fixes (adding namespace existence check for better reverts)
packages/world/src/modules/core/implementations/AccessManagementSystem.sol
Outdated
Show resolved
Hide resolved
Co-authored-by: Kevin Ingersoll <[email protected]>
// Require namespace ID to be a valid namespace | ||
requireNamespace(namespaceId); | ||
|
||
// Require the caller to own the namespace | ||
AccessControl.requireOwner(namespaceId, _msgSender()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Require namespace ID to be a valid namespace | |
requireNamespace(namespaceId); | |
// Require the caller to own the namespace | |
AccessControl.requireOwner(namespaceId, _msgSender()); | |
// Require namespace ID to be a valid namespace | |
requireNamespace(namespaceId); | |
// Require the namespace to exist | |
AccessControl.requireExistence(namespaceId); | |
// Require the caller to own the namespace | |
AccessControl.requireOwner(namespaceId, _msgSender()); |
A few suggestions were fixed in previous PR's.
#2007 fixed
registerTable
:#2007 fixed
registerSystem
:#2096 added
unregisterDelegation
: